Átfogó útmutató globális fejlesztők számára a szolgáltatási háló Python mikroszolgáltatásokkal történő megvalósításához. Ismerje meg az Istio-t, a Linkerdet, a biztonságot, a megfigyelhetőséget és a forgalomkezelést.
Python Mikroszolgáltatások: Mélyrehatóan a Szolgáltatási Háló Implementációjáról
A szoftverfejlesztési környezet alapvetően átalakult a mikroszolgáltatás architektúra felé. A monolitikus alkalmazások kisebb, egymástól függetlenül telepíthető szolgáltatásokra bontása páratlan agilitást, méretezhetőséget és rugalmasságot kínál. A Python, tiszta szintaxisával és olyan hatékony keretrendszerekkel, mint a FastAPI és a Flask, a mikroszolgáltatások felépítésének első számú választásává vált. Ez az elosztott világ azonban nem mentes a kihívásoktól. Ahogy a szolgáltatások száma nő, úgy nő az interakcióik kezelésének összetettsége is. Itt jön képbe a szolgáltatási háló.
Ez az átfogó útmutató a szoftvermérnökök, a DevOps szakemberek és a Python-nal dolgozó építészek globális közönségének szól. Megvizsgáljuk, hogy a szolgáltatási háló miért nem csupán egy "jó dolog", hanem egy elengedhetetlen összetevő a mikroszolgáltatások méretarányos futtatásához. Demisztifikáljuk, hogy mi a szolgáltatási háló, hogyan oldja meg a kritikus működési kihívásokat, és gyakorlati bepillantást nyújtunk a Python-alapú mikroszolgáltatás-környezetben történő megvalósításba.
Mik azok a Python mikroszolgáltatások? Egy gyors felfrissítő
Mielőtt belemerülnénk a hálóba, állítsunk fel egy közös alapot. A mikroszolgáltatás architektúra egy olyan megközelítés, ahol egyetlen alkalmazás sok lazán kapcsolt és egymástól függetlenül telepíthető kisebb szolgáltatásból áll. Minden szolgáltatás önálló, egy adott üzleti képességért felelős, és hálózaton keresztül kommunikál más szolgáltatásokkal, jellemzően API-kon (például REST vagy gRPC) keresztül.
A Python kivételesen alkalmas ehhez a paradigmához a következő okok miatt:
- Egyszerűség és a fejlesztés sebessége: A Python olvasható szintaxisa lehetővé teszi a csapatok számára, hogy gyorsan építsenek és iteráljanak a szolgáltatásokon.
- Gazdag ökoszisztéma: A könyvtárak és keretrendszerek hatalmas gyűjteménye mindentől a webszerverektől (FastAPI, Flask) az adattudományig (Pandas, Scikit-learn).
- Teljesítmény: A modern aszinkron keretrendszerek, mint a FastAPI, a Starlette és a Pydantic alapjain, a NodeJS-szel és a Go-val összehasonlítható teljesítményt nyújtanak az I/O-kötött feladatokhoz, amelyek gyakoriak a mikroszolgáltatásokban.
Képzeljünk el egy globális e-kereskedelmi platformot. Az egy hatalmas alkalmazás helyett mikroszolgáltatásokból állhat, mint például:
- Felhasználói Szolgáltatás: Felhasználói fiókokat és hitelesítést kezel.
- Termékszolgáltatás: A termékkatalógust és a készletet kezeli.
- Rendelésszolgáltatás: Új rendeléseket és fizetést dolgoz fel.
- Szállítási Szolgáltatás: Szállítási költségeket számít ki és intézi a szállítást.
A Rendelésszolgáltatás, amelyet Pythonban írtak, a Felhasználói Szolgáltatással kell beszélnie az ügyfél érvényesítéséhez, és a Termékszolgáltatással a készlet ellenőrzéséhez. Ez a kommunikáció a hálózaton keresztül történik. Most szorozza meg ezt több tucat vagy több száz szolgáltatással, és az összetettség kezd megjelenni.
Az elosztott architektúra inherens kihívásai
Amikor az alkalmazás komponensei hálózaton keresztül kommunikálnak, örökli a hálózat összes inherens megbízhatatlanságát. A monolitikus egyszerű függvényhívása egy komplex hálózati kéréssé válik, tele potenciális problémákkal. Ezeket gyakran "2. napos" működési problémáknak nevezzük, mert a kezdeti telepítés után válnak nyilvánvalóvá.
Hálózati megbízhatatlanság
Mi történik, ha a Termékszolgáltatás lassan válaszol vagy ideiglenesen nem érhető el, amikor a Rendelésszolgáltatás hívja? A kérés sikertelen lehet. Az alkalmazáskódnak most ezt kell kezelnie. Újra meg kell próbálni? Hányszor? Milyen késleltetéssel (exponenciális visszahúzás)? Mi van, ha a Termékszolgáltatás teljesen leállt? Le kell állítanunk a kérések küldését egy ideig, hogy helyreálljon? Ezt a logikát, beleértve az újrapróbálkozásokat, a lejárati időket és az áramkör-megszakítókat, minden szolgáltatásban, minden hívásnál meg kell valósítani. Ez redundáns, hibára hajlamos, és rendetlenséget okoz a Python üzleti logikájában.
A megfigyelhetőség üressége
Egy monolitban a teljesítmény megértése viszonylag egyszerű. Egy mikroszolgáltatás-környezetben egyetlen felhasználói kérés átmehet öt, tíz vagy még több szolgáltatáson. Ha ez a kérés lassú, hol van a szűk keresztmetszet? Ennek megválaszolásához egységes megközelítésre van szükség:
- Mérések: A mérőszámok (például a kérés késleltetése, a hibaarányok és a forgalom volumene (az úgynevezett "Arany jelek") következetes gyűjtése minden szolgáltatásból.
- Naplózás: A naplók összesítése több száz szolgáltatáspéldányból, és korrelálásuk egy adott kéréssel.
- Elosztott nyomkövetés: Egyetlen kérés útjának követése az összes általa érintett szolgáltatáson keresztül a teljes hívási gráf vizualizálása és a késések azonosítása érdekében.
Ennek manuális megvalósítása nagyszabású műszerezési és monitoring könyvtárak hozzáadását jelenti minden Python-szolgáltatáshoz, ami inkonzisztens lehet, és karbantartási többletköltséget jelenthet.
A biztonsági labirintus
Hogyan biztosítja, hogy a Rendelésszolgáltatás és a Felhasználói Szolgáltatás közötti kommunikáció biztonságos és titkosított legyen? Hogyan garantálja, hogy csak a Rendelésszolgáltatás férhessen hozzá a Termékszolgáltatás érzékeny készletvégpontjaihoz? Egy hagyományos beállításban a hálózati szintű szabályokra (tűzfalak) támaszkodhat, vagy titkosítási és hitelesítési logikát ágyazhat be az egyes alkalmazásokba. Ez nagymértékben nehézkessé válik a skálán történő kezelés során. Egy nulla megbízhatóságú hálózatra van szüksége, ahol minden szolgáltatás hitelesíti és engedélyezi az egyes hívásokat, ezt a koncepciót Mutual TLS (mTLS)-nek és finomszemcsés hozzáférés-vezérlésnek nevezik.
Komplex telepítések és forgalomkezelés
Hogyan adhat ki egy új verziót a Python-alapú Termékszolgáltatásából anélkül, hogy leállást okozna? Egy gyakori stratégia a kanári kiadás, ahol lassan a valós forgalom kis százalékát (pl. 1%) irányítja az új verzióba. Ha jól teljesít, fokozatosan növeli a forgalmat. Ennek megvalósítása gyakran összetett logikát igényel a terheléselosztó vagy az API-átjáró szintjén. Ugyanez vonatkozik az A/B tesztelésre vagy a forgalom tükrözésére tesztelési célokra.
Lépjünk be a szolgáltatási hálóba: A szolgáltatások hálózata
A szolgáltatási háló egy dedikált, konfigurálható infrastruktúraréteg, amely ezeket a kihívásokat kezeli. Ez egy hálózati modell, amely a meglévő hálózata tetején helyezkedik el (például a Kubernetes által biztosított), hogy kezelje az összes szolgáltatás-szolgáltatás közötti kommunikációt. Elsődleges célja, hogy ezt a kommunikációt megbízhatóvá, biztonságossá és megfigyelhetővé tegye.
Alapvető összetevők: Kontroll sík és adatsík
A szolgáltatási hálónak két fő része van:
- Az adatsík: Ezt egy sor könnyű hálózati proxyszerver alkotja, az úgynevezett mellékkocsik, amelyeket a mikroszolgáltatás minden példánya mellé telepítenek. Ezek a proxyszerverek elfogják az összes bejövő és kimenő hálózati forgalmat a szolgáltatásból és a szolgáltatásba. Nem tudják, hogy a szolgáltatást Pythonban írták, és nem is törődnek vele; a hálózati szinten működnek. A szolgáltatási hálókban használt legnépszerűbb proxy az Envoy.
- A kontroll sík: Ez a szolgáltatási háló "agya". Ez egy sor olyan komponens, amellyel Ön, az üzemeltető interakcióba lép. Magas szintű szabályokat és házirendeket ad meg a kontroll sík számára (pl. "próbálkozzon újra a Termékszolgáltatáshoz intézett sikertelen kérésekkel legfeljebb 3-szor"). A kontroll sík ezt a politikát konfigurációkká fordítja, és átnyomja az adatsíkban lévő összes mellékkocsi proxyszerverhez.
A lényeg a következő: a szolgáltatási háló a hálózati problémák logikáját az egyes Python-szolgáltatásokból a platformrétegbe helyezi át. A FastAPI fejlesztőnek többé nem kell újrapróbálkozó könyvtárat importálnia, vagy kódot írnia az mTLS tanúsítványok kezeléséhez. Üzleti logikát írnak, és a háló a többit transzparensen kezeli.
A Rendelésszolgáltatásból a Termékszolgáltatáshoz érkező kérés most így folyik: Rendelésszolgáltatás → Rendelésszolgáltatás mellékkocsi → Termékszolgáltatás mellékkocsi → Termékszolgáltatás. Az összes varázslat – az újrapróbálkozások, a terheléselosztás, a titkosítás, a mérőszámok gyűjtése – a két mellékkocsi között történik, a kontroll sík által kezelve.
A szolgáltatási háló alapvető pillérei
Bontsuk le a szolgáltatási háló által nyújtott előnyöket négy kulcsfontosságú pillérre.
1. Megbízhatóság és rugalmasság
A szolgáltatási háló robusztusabbá teszi az elosztott rendszert anélkül, hogy módosítaná az alkalmazáskódot.
- Automatikus újrapróbálkozások: Ha egy szolgáltatáshívás átmeneti hálózati hibával meghiúsul, a mellékkocsi a konfigurált házirend alapján automatikusan újrapróbálkozhat a kéréssel.
- Időtúllépések: Következetes, szolgáltatásszintű időtúllépéseket kényszeríthet ki. Ha egy downstream szolgáltatás nem válaszol 200 ms-en belül, a kérés gyorsan meghiúsul, megakadályozva az erőforrások visszatartását.
- Áramkör-megszakítók: Ha egy szolgáltatáspéldány folyamatosan meghiúsul, a mellékkocsi ideiglenesen eltávolíthatja a terheléselosztó készletből (kioldja az áramkört). Ez megakadályozza a kaszkádolt hibákat, és időt ad a nem megfelelő szolgáltatás helyreállításához.
2. Mély megfigyelhetőség
A mellékkocsi proxy tökéletes kiindulópont a forgalom megfigyeléséhez. Mivel minden kérést és választ lát, automatikusan rengeteg telemetriai adatot generálhat.
- Mérések: A háló automatikusan részletes metrikákat generál az összes forgalomhoz, beleértve a késést (p50, p90, p99), a sikerességi arányokat és a kérések volumenét. Ezeket egy olyan eszközzel, mint a Prometheus, össze lehet gyűjteni, és egy olyan műszerfalon, mint a Grafana, vizualizálni.
- Elosztott nyomkövetés: A mellékkocsik nyomkövetési fejlécet (például B3 vagy W3C Trace Context) injektálhatnak és terjeszthetnek a szolgáltatáshívások között. Ez lehetővé teszi az olyan nyomkövető eszközök számára, mint a Jaeger vagy a Zipkin, hogy összekapcsolják a kérés teljes útját, teljes képet adva a rendszer viselkedéséről.
- Hozzáférési naplók: Következetes, részletes naplókat kaphat minden egyes szolgáltatás-szolgáltatás híváshoz, a forrást, a célt, az utat, a késleltetést és a válasz kódot mutatva, mindezt egyetlen `print()` utasítás nélkül a Python-kódjában.
Az olyan eszközök, mint a Kiali, akár ezt az adatot is felhasználhatják a mikroszolgáltatások élő függőségi gráfjának generálásához, amely valós időben mutatja a forgalom áramlását és az állapotot.
3. Univerzális biztonság
A szolgáltatási háló zéró-megbízhatóságú biztonsági modellt kényszeríthet ki a klaszteren belül.
- Mutual TLS (mTLS): A háló automatikusan kriptográfiai identitásokat (tanúsítványokat) adhat ki minden szolgáltatásnak. Ezt követően ezekkel titkosítja és hitelesíti a szolgáltatások közötti összes forgalmat. Ez biztosítja, hogy egyetlen hitelesítetlen szolgáltatás sem tud kommunikálni egy másik szolgáltatással, és a tranzitban lévő összes adat titkosított. Ez egy egyszerű konfigurációs kapcsolóval kapcsolható be.
- Engedélyezési házirendek: Létrehozhat hatékony, finomszemcsés hozzáférés-vezérlési szabályokat. Például írhat egy olyan házirendet, amely kimondja: "Engedélyezze a `GET` kéréseket a `rendeles-szolgaltatas` identitással rendelkező szolgáltatásoktól a `termekek` végpontra a `termek-szolgaltatas`-ban, de tagadjon meg mindent". Ezt a mellékkocsi szintjén kényszerítik ki, nem a Python-kódban, ami sokkal biztonságosabbá és auditálhatóvá teszi.
4. Rugalmas forgalomkezelés
Ez a szolgáltatási háló egyik leghatékonyabb funkciója, amely pontos ellenőrzést biztosít a forgalom rendszeren való átfolyása felett.
- Dinamikus útválasztás: Útválasztási kérések fejlécek, sütik vagy más metaadatok alapján. Például irányítsa a béta felhasználókat egy szolgáltatás új verziójába egy adott HTTP-fejléc ellenőrzésével.
- Kanári kiadások és A/B tesztelés: Valósítson meg kifinomult telepítési stratégiákat a forgalom százalékos arány szerinti felosztásával. Például küldje a forgalom 90%-át a Python szolgáltatás `v1` verziójába, és 10%-át az új `v2` verzióba. Figyelheti a `v2` metrikáit, és ha minden rendben van, fokozatosan tolja át a több forgalmat, amíg a `v2` a 100%-ot kezeli.
- Hiba injektálás: A rendszer rugalmasságának teszteléséhez a hálót használhatja a hibák, például a 503-as HTTP-hibák vagy a hálózati késések szándékos bejuttatására, a meghatározott kérésekhez. Ez segít megtalálni és kijavítani a gyengeségeket, mielőtt azok valós leállást okoznának.
A szolgáltatási háló kiválasztása: Globális perspektíva
Számos érett, nyílt forráskódú szolgáltatási háló érhető el. A választás a szervezet igényeitől, a meglévő ökoszisztémától és az operatív kapacitástól függ. A három legkiemelkedőbb az Istio, a Linkerd és a Consul.
Istio
- Áttekintés: A Google, az IBM és mások támogatják, az Istio a legtöbb funkcióval rendelkező és leghatékonyabb szolgáltatási háló. A bevált Envoy proxyt használja.
- Erősségek: Páratlan rugalmasság a forgalomkezelésben, hatékony biztonsági házirendek és egy vibráló ökoszisztéma. Ez a de facto szabvány a komplex, vállalati szintű telepítésekhez.
- Megfontolások: Ereje az összetettséggel jár. A tanulási görbe meredek lehet, és a többi hálóhoz képest magasabb erőforrás-igénnyel rendelkezik.
Linkerd
- Áttekintés: Egy CNCF (Cloud Native Computing Foundation) végzett projekt, amely az egyszerűséget, a teljesítményt és az üzemeltetési könnyedséget helyezi előtérbe.
- Erősségek: Hihetetlenül egyszerű a telepítése és a használatának megkezdése. Nagyon alacsony az erőforrásigénye a Rust-ban írt, egyedi építésű, ultralightweight proxy-jának köszönhetően. Az olyan funkciók, mint az mTLS, konfiguráció nélkül működnek.
- Megfontolások: Véleményesebb és fókuszáltabb funkciókészlettel rendelkezik. Míg kivételesen jól fedi a megfigyelhetőség, a megbízhatóság és a biztonság alapvető felhasználási eseteit, hiányoznak belőle az Istio bizonyos fejlett, ezoterikus forgalomirányítási képességei.
Consul Connect
- Áttekintés: A HashiCorp eszközök szélesebb körének része (amely magában foglalja a Terraformot és a Vaultot). Kulcsfontosságú megkülönböztetője a több platformos környezetekhez nyújtott első osztályú támogatása.
- Erősségek: A legjobb választás hibrid környezetekhez, amelyek több Kubernetes klasztert, különböző felhőszolgáltatókat, sőt virtuális gépeket vagy bare-metal szervereket ölelnek fel. Az integrációja a Consul szolgáltatáskatalógussal zökkenőmentes.
- Megfontolások: Egy nagyobb termék része. Ha csak egy szolgáltatási hálózatra van szüksége egyetlen Kubernetes klaszterhez, a Consul többet kínálhat, mint amire szüksége van.
Gyakorlati megvalósítás: Python mikroszolgáltatás hozzáadása a szolgáltatási hálóhoz
Gondoljunk végig egy koncepcionális példát arra, hogyan adhatna hozzá egy egyszerű Python FastAPI szolgáltatást egy Istio-hoz hasonló hálóhoz. Ennek a folyamatnak a szépsége, hogy mennyit kell megváltoztatnia a Python alkalmazásában.
Forgatókönyv
Van egy egyszerű `felhasznalo-szolgaltatas` Pythonban írva a FastAPI használatával. Egy végpontja van: `/felhasznalok/{felhasznalo_id}`.
1. lépés: A Python szolgáltatás (nincs hálóspecifikus kód)
Az alkalmazáskód tiszta üzleti logika marad. Nincsenek importok az Istio, a Linkerd vagy az Envoy számára.
fo.py:
from fastapi import FastAPI
app = FastAPI()
felhasznalok_db = {
1: {"nev": "Alice", "hely": "Globális"},
2: {"nev": "Bob", "hely": "Nemzetközi"}
}
@app.get("/felhasznalok/{felhasznalo_id}")
def olvas_felhasznalo(felhasznalo_id: int):
return felhasznalok_db.get(felhasznalo_id, {"hiba": "Felhasználó nem található"})
A mellékelt `Dockerfile` is szabványos, különleges módosítások nélkül.
2. lépés: Kubernetes telepítés
A szolgáltatás telepítését és szolgáltatását a standard Kubernetes YAML-ban definiálja. Itt semmi sem vonatkozik a szolgáltatási hálóra.
apiVersion: apps/v1
kind: Deployment
metadata:
name: felhasznalo-szolgaltatas-v1
spec:
replicas: 1
selector:
matchLabels:
app: felhasznalo-szolgaltatas
version: v1
template:
metadata:
labels:
app: felhasznalo-szolgaltatas
version: v1
spec:
containers:
- name: felhasznalo-szolgaltatas
image: a-repo/felhasznalo-szolgaltatas:v1
ports:
- containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
name: felhasznalo-szolgaltatas
spec:
selector:
app: felhasznalo-szolgaltatas
ports:
- port: 80
targetPort: 8000
3. lépés: A mellékkocsi proxy injektálása
Itt történik a varázslat. Miután telepítette a szolgáltatási hálót (pl. Istio) a Kubernetes klaszterébe, engedélyezi az automatikus mellékkocsi injekciót. Az Istio esetében ez egy egyszeri parancs a névtér számára:
kubectl label namespace default istio-injection=enabled
Most, amikor telepíti a `felhasznalo-szolgaltatas`-t a `kubectl apply -f a-telepitese.yaml` segítségével, az Istio kontroll síkja automatikusan mutálja a pod specifikációját, mielőtt létrejönne. Hozzáadja az Envoy proxy tárolóját a podhoz. A podnak most két tárolója van: a Python `felhasznalo-szolgaltatas` és az `istio-proxy`. Egyáltalán nem kellett megváltoztatnia a YAML-t.
4. lépés: Szolgáltatási háló házirendek alkalmazása
A Python-szolgáltatása most a háló része! A szolgáltatásba és onnan érkező összes forgalmat proxizzák. Most hatékony házirendeket alkalmazhat. Kényszerítsünk szigorú mTLS-t a névtérben lévő összes szolgáltatásra.
csoport-hitelesites.yaml:
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: default
spec:
mtls:
mode: STRICT
Ennek az egyetlen, egyszerű YAML-fájlnak az alkalmazásával titkosította és hitelesítette a névtérben lévő összes szolgáltatás-szolgáltatás kommunikációt. Ez hatalmas biztonsági nyereség, nulla alkalmazáskód-változással.
Most hozzunk létre egy forgalom-útválasztási szabályt a kanári kiadás végrehajtásához. Tegyük fel, hogy telepítve van egy `felhasznalo-szolgaltatas-v2`.
virtualis-szolgaltatas.yaml:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: felhasznalo-szolgaltatas
spec:
hosts:
- felhasznalo-szolgaltatas
http:
- route:
- destination:
host: felhasznalo-szolgaltatas
subset: v1
weight: 90
- destination:
host: felhasznalo-szolgaltatas
subset: v2
weight: 10
Ezzel a `VirtualService`-szel és egy megfelelő `DestinationRule`-lal (amely meghatározza a `v1` és `v2` részhalmazokat) arra utasította az Istio-t, hogy a forgalom 90%-át a régi szolgáltatásába, 10%-át pedig az újba küldje. Mindez az infrastruktúra szintjén történik, teljesen átlátható a Python alkalmazások és a hívóik számára.
Mikor érdemes szolgáltatási hálót használni? (És mikor nem)
A szolgáltatási háló egy hatékony eszköz, de nem univerzális megoldás. Egy ilyennek az elfogadása egy újabb infrastruktúraréteget ad a kezeléshez.
Fogadjon el egy szolgáltatási hálót, ha:
- A mikroszolgáltatások száma növekszik (jellemzően 5-10 szolgáltatáson túl), és az interakcióik kezelése fejfájássá válik.
- Poliglot környezetben működik, ahol a Pythonban, Go-ban és Javában írt szolgáltatások egységes házirendjeinek kikényszerítése követelmény.
- Szigorú biztonsági, megfigyelhetőségi és rugalmassági követelményei vannak, amelyeket nehéz az alkalmazási szinten teljesíteni.
- A szervezet külön fejlesztési és üzemeltetési csapatokkal rendelkezik, és szeretné képessé tenni a fejlesztőket az üzleti logikára való összpontosításra, miközben az üzemeltetési csapat kezeli a platformot.
- Nagymértékben befektetett a konténer-orchestrációba, különösen a Kubernetesbe, ahol a szolgáltatási hálók a legzökkenőmentesebben integrálódnak.
Fontolja meg az alternatívákat, ha:
- Monolitja van, vagy csak egy marék szolgáltatása. A háló működési többletköltsége valószínűleg meghaladja az előnyeit.
- A csapata kicsi, és nincs kapacitása új, komplex infrastrukturális komponens megismerésére és kezelésére.
- Az alkalmazása a lehető legalacsonyabb késleltetést igényli, és a mellékkocsi proxy által hozzáadott mikroszekundumos szintű többletterhelés elfogadhatatlan az Ön használati esetében.
- A megbízhatósági és rugalmassági igényei egyszerűek, és jól karbantartott alkalmazásszintű könyvtárakkal megfelelően megoldhatók.
Következtetés: A Python mikroszolgáltatások felhatalmazása
A mikroszolgáltatási utazás a fejlesztéssel kezdődik, de gyorsan működési kihívássá válik. Ahogy a Python-alapú elosztott rendszere nő, a hálózatépítés, a biztonság és a megfigyelhetőség összetettsége túlterhelheti a fejlesztőcsapatokat, és lelassíthatja az innovációt.
A szolgáltatási háló ezeket a kihívásokat közvetlenül kezeli, azáltal, hogy elvonja őket az alkalmazásból, és egy dedikált, nyelvtől független infrastruktúrarétegbe helyezi át. Egységes módot biztosít a szolgáltatások közötti kommunikáció ellenőrzésére, biztosítására és megfigyelésére, függetlenül attól, hogy milyen nyelven írták őket.
Ha olyan szolgáltatási hálót fogad el, mint az Istio vagy a Linkerd, felhatalmazza a Python fejlesztőit, hogy azt tegyék, amit a legjobban tudnak: kiváló funkciókat építeni és üzleti értéket nyújtani. Mentesülnek az összetett, boilerplate hálózatépítési logika megvalósításának terhe alól, és ehelyett a platformra támaszkodhatnak a rugalmasság, a biztonság és a betekintés biztosításához. Bármely szervezet számára, amely komolyan veszi a mikroszolgáltatási architektúrájának skálázását, a szolgáltatási háló stratégiai befektetés, amely megbízhatóságot, biztonságot és fejlesztői termelékenységet hoz.